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Dear Sir: 



Applicants request review of the rejection in the above -identified application. No amendments are 
being filed with this request. This request is being filed with a notice of appeal. The review is requested for the 
reasons stated below. 

Claims 1-31 remain pending in the application. Reconsideration of the present case is earnestly 
requested in light of the following remarks. Please note that for brevity, only the primary arguments directed to 
the independent claims are presented, and that additional arguments, e.g., directed to the subject matter of the 
dependent claims, will be presented if and when the case proceeds to Appeal. 

The Examiner rejected claims 1-5, 7-12, 14 and 17-31 under 35 U.S.C. § 102(e) as being anticipated by 
Carre (U.S. Patent 6,282,579). Applicants respectfully traverse this rejection for at least the reasons below. 

Regarding claim 1, Carre fails to disclose a client generating a request for type information for an 
attribute or event, contrary to the Examiner's contention. Carre pertains to address conversion between 
CORBA objects and OSI objects (Carre - col. 1, lines 9-19; col. 1, line 59 - col. 2, line 46) and to the 
transforming of object interfaces column 5, lines 49-59). The Examiner cites the Abstract, FIG. 2A, 2B, as well 
as column 3, lines 18-55 and column 5, lines 4-38 of Carre. However, Carre does not mention anything about a 
client generating a request for type information, either at the Examiner's cited passages or elsewhere. In order 
to permit address interaction between objects that use different addressing modes, Carre's system converts an 
address type with an address value according to one addressing mode to a corresponding type of another 
specification language or addressing mode. (Carre, column 1, line 59 - column 2, line 6; column 2, lines 11-14; 
lines 25-28; and lines 34- 39). Thus, Carre is concerned with converting address types and object interfaces, but 
fails to teach anything regarding a client generating a request for type information. Converting address types 
and object interfaces does not disclose a' client generating a request for type information. 
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Carre teaches that client objects request services provided by service objects. Carre further teaches that 
a client object sends a request message to a service object that contains an operation, a target object, one or more 
parameters, and, optionally, a request context (Carre, column 3, lines 47-53). Carre also teaches that Object 
Request Brokers (ORBs) use a Remote Procedure Call (RPC) mechanism to route request messages to the target 
object (Carre, column 4, lines 1-6). In order to allow objects defined using different specifications, such as 
ASN.l and IDL, to communicate Carre teaches that the objects and addresses are converted between the two 
standards. However, Carre does not mention anything regarding a client generating a request for type 
information for an attribute or event. The clients in Carre's system do not request type information, but instead 
request a specific service from a particular server object and Carre's system automatically makes any 
conversions between different object specification languages necessarily to allow the client and server object to 
communicate. Thus, there is no need in Carre's system for a client to generate a request for type information for 
an attribute or event. In fact, the purpose of Carre's teachings appears to be to perform the address type 
conversion for the client so that the client does not have to modify it's own interface in order to communicate 
with an object employing a different addressing mode. See, e.g., col. 1, line 43 - col. 2, line 6. Therefore, 
Carre actually teaches away from a client generating a request for type information for an attribute or 
event. 

In the Response to Arguments, the Examiner repeats the previous arguments and citations. However, as 
noted above, Carre's requests are not requests for type information for an attribute or event. Instead, Carre's 
client requests a specific service from a particular server. 

Carre also fails to disclose sending the request for type information to an object request broker. 

The Examiner cites Carre's Object Request Broker of FIG. 3a. However, FIG. 3a illustrates a CMISE gateway 
to aid communication between objects by converting ASN types to a corresponding IDL types. FIG. 3a does not 
illustrate a client sending a request for type information to an object request broker. As noted above, clients of 
Carre's system send specific request messages to Object Request Brokers that include an operation, a target 
object, one or more parameters, and, optionally, a request context. Neither clients nor any other entities in 
Carre's send requests for type information to object request brokers. 

In the Response to Arguments, the Examiner again cites fig. 3a of Carre, but also cites column 5, lines 
39-65 and column 6, lines 1 - 35. At column 5, lines 39- 65, Carre describes that the interface unit GDMO/IDL 
"translates the OSI objects OM and OA of the components from GDMO to IDL". Carre teaches that an "object 
so specified can be accessed by classic CORBA messages." This section of Carre has no relevance to a client 
sending a request for type information to an object request broker. 

The Examiner's other citation (column 6, lines 1 - 35) describes the steps involved in the address-type 
conversion used in Carre's system. Specifically, Carre describes how the ASN type of an OSI address value is 
converted to a correspondent IDL type that is structured to contain and transport both the CMIS/OSI full 
distinguished name and the CORBA object reference. However, as noted above, the mere fact that Carre's 
system includes converting address types as part of communication between CORBA entities and OSI entities 
does not disclose or anticipate the specific limitation of sending a request for type information to an object 
request broker. 

Carre further fails to disclose a metadata gateway receiving the request for type information from 
the object request broker. The Examiner cites the CMISE Gateway of FIG. 3a and column 5, lines 39-65. 
However, the cited passage does not mention anything about a metadata gateway receiving a request for type 
information from an object request broker. FIG. 3a also fails to show anything about a metadata gateway 
receiving a request for type information. Carre teaches that by converting objects from the ASN.l specification 
to the IDL specification CMISE operations can be performed on CORBA objects, and vice versa (column 5, 
lines 24-39 and lines 60-65) but fails to teach anything about a metadata gateway receiving a request for type 
information from an object request broker. Applicants note that the Examiner has failed to respond to this 
argument in the Response to Arguments. 
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Carre additionally does not disclose reading the type information from a metadata repository, 
wherein the type information is stored in a database format in the metadata repository. The Examiner cites 
CMISE/IDL FIG. 3. However, the cited CMISE/IDL is not a metadata repository from which type information 
is read. In response, the Examiner refers to "using CMISE/IDL fig. 3 as a metadata repository to manage/store 
the OSI objects translated from type conversion" and also cites column 6, lines 1 - 35 of Carre. Column 6, lines 
1 - 35 describe the conversion of ASN types to a correspondent EDL type. However, Carre teaches that the 
CMISE/IDL is an "interface unit" that contains the "CMISE object and the services assigned to this object". 
Carre also teaches that the CMISE object is specified by an IDL interface and acts, and thus appears, like a 
CORBA object (Carre, column 5, lines 21-39). Thus, the CMISE/IDL cited by the Examiner is a 
communication interface that allows non-CORBA objects to be interacted with via standard CORBA interfaces. 
The CMISE/IDL interface unit is clearly not a metadata repository. Moreover, Applicants' claim specifically 
recites that type information is stored in a database format in the metadata repository. Carre's gateway does not 
store type information in a database format and thus cannot be considered the metadata repository of Applicants' 
claim. 

Carre also fails to disclose the client receiving the translated type information for the attribute or 
event through the object request broker. The Examiner cites column 6, lines 10-35 of Carre. However, this 
portion of Carre does not describe a client receiving the translated type information for the attribute or event 
through the object request broker. Instead, as noted above, the cited passage is part of a description of 
converting objects from ASN to IDL and vice versa as well as caching of converting object instances. As 
described above, converting CMISE and CORBA objects is not the same as client generating a request to type 
information, and receiving the translated type information for the attribute or event through an object request 
broker. The Examiner's cited passage makes no mention of any client receiving translated type information for 
an attribute or event through an object request broker. 

The Examiner asserts in the Response to Arguments, "Applicants clearly have still failed to identify 
specific claim limitations that would define clearly patentable distinction over prior art." However, as discussed 
above, Carre fails to disclose the specific claim limitations of a client generating a request for type information 
for an attribute or event, sending the request for type information to an object request broker, a metadata 
gateway receiving the request for type information from the object request broker, reading the type information 
from a metadata repository, and the client receiving the translated type information for the attribute or event 
through the object request broker. Thus, the Examiner statement regarding Applicants not identifying specific 
claim limitations is clearly incorrect. 

Anticipation requires the presence in a single prior art reference disclosure of each and every limitation 
of the claimed invention, arranged as in the claim . M.P.E.P 2131; Lindemann Maschinenfabrik GmbH v. 
American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must be shown in 
as complete detail as is contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Carre fails to disclose a client generating a request for type information for an 
attribute or event, a metadata gateway receiving the request for type information from an object request broker, 
reading the type information from a metadata repository, and the client receiving translated type information for 
the attribute or event through an object request broker. Therefore, for numerous reasons, Carre clearly cannot be 
said to anticipate claim 1 . Similar remarks as those above regarding claim 1 also apply to claim 22. 

Regarding claim 10, Carre fails to disclose a client generating a request to encode type information 
for an object, attribute, or event. The Examiner cites the Abstract, FIG. 2 A and 2B as well as column 3, lines 
18-55 and column 5, lines 4-38. The Examiner also specifically refers to Agent 1 of FIG. 3 a, equating Agent 1 
to the client of claim 10. However, Carre does not, either at the Examiner's cited passages or elsewhere, 
describe Agent 1 or any other client, generating a request to encode type information for an object, attribute, or 
event. As noted above regarding the rejection of claim 1, Carre is concerned with providing interface and 
address type conversions to allow objects specified according to different specification languages, such as ASN 
and EDL, to communicate and interact with each other by providing interfaces that allow non-CORBA objects to 
appear as CORBA objects to the outside world. Clients in Carre's system do not generate requests to encode 
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type information for objects, attributes or events. Instead, client objects in Carre's system invoke, via a standard 
CORBA interface, services provided by server objects. (Carre, column 1, lines 9-19; column 1, line 59-column 
2, line 46; column 5, lines 49-59). Nowhere does Carre mention a client generating a request to encode type 
information for an object attribute or event. 

In the Response to Arguments, the Examiner again refers to Carre's teachings regarding type 
translation, citing column 3, lines 18 - 55 and column 5, lines 20 - 58. However, Carre's address conversion 
has nothing to with a client generating a request to encode type information for an object, attribute or event. 
Instead, Carre's address type conversion is performed as part of communicating with CMISE object that appear 
as CORBA objects. Nowhere does Carre mention a client generating a request to encode type information. 
Instead, Carre's interface unit converts object instances and object instance values into an EDL type to allow 
communication between CORBA objects and CMISE objects. 

Additionally, Carre does not disclose sending the request to an object request broker and a 
metadata gateway receiving the request to encode type information from the object request broker. The 

Examiner cites ORB and CMISE Gateway of FIG. 3a. However, Carre does not describe the ORB of FIG. 3a as 
receiving a request to encode type information from a client. Nor does Carre describe the CMISE Gateway as 
receiving the request from the ORB. Instead, Carre teaches object request brokers provide an infrastructure that 
enables objects tp communicate in a distributed environment such that "it makes no difference to" the requesting 
objects in which computer system or in which form the target object is implemented (Carre, column 3, lines 56- 
63). Carre also teaches that a requesting object sends a request message to an object request broker and that the 
object request broker routes the request message to the target object (Carre, column 3, line 64-column 4, line 6). 
Thus, Carre teaches that object request brokers route request messages from a request object to the target object. 
Carre does not mention anything about object request brokers receiving requests to encode type information 
from a client or about a metadata gateway receiving such request from an object request broker. 

Carre further fails to disclose storing the type information in a metadata repository, where the 
type information is stored in a database format in the metadata repository. The Examiner cites CMISE/IDL of 
FIG. 3 and column 6, lines 10-35, specifically referring to Carre's conversion of address types from OSI types. 
However, the portions of Carre cited by the Examiner refer to the caching of structures, such as object instance 
values and object reference pairs for addresses already in an entity. Caching of object values and references is 
not the same as storing type information in a database format in a metadata repository. Additionally, as noted 
above regarding the rejection of claim 1, the CMISE/IDL interface unit cited by the Examiner is clearly a 
communication interface that allows non-CORBA objects to be interacted with via standard CORBA interfaces 
(Carre, column 5, lines 21-39). The CMISE/IDL interface unit is clearly not a metadata repository. Moreover, 
Carre does not describe or even mention anything regarding storing type information in the CMISE/IDL 
interface unit. 

As discussed above, Carre fails to disclose the specific limitations as arranged in claim 10 and thus 
Carre fails to anticipate claim 10. Similar remarks as those above regarding claim 10 apply to claim 27 as well. 

Regarding claim 14, Carre fails to disclose a metadata repository comprising metadata concerning 
object classes for a plurality of managed objects, wherein the metadata comprises information expressed in a 
database format, and wherein the managed objects correspond to managed devices on a network. The Examiner 
cites CMISE/IDL of FIG. 3a as well as the abstract, FIGs 2A, 3 A, column 3, lines 18-55 and column 5, lines 4- 
38 of Carre. However, as noted above, regarding the rejections of claim 1 and 10, the CMISE/IDL interface unit 
cited by the Examiner is clearly a communication interface that allows non-CORBA objects to be interacted 
with via standard CORBA interfaces (Carre, column 5, lines 21-39). The CMISE/IDL interface unit is clearly 
not a metadata repository. Moreover, Carre does not describe or even mention anything regarding storing 
metadata concerning object classes in the CMISE/IDL interface unit. Nowhere does Carre describe anything 
about storing metadata concerning object classes in a metadata repository. 
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Carre also fails to disclose a metadata gateway coupled to the metadata repository and to an object 
request broker, where the metadata gateway is operable to send and receive metadata from the database, where 
the metadata gateway provides translation of the metadata to and from the database format and an interface 
definition language. The Examiner again cites CMISE Gateway of FIG. 3a. However, Carre's CMISE Gateway 
provides address type conversion between two different object interface specifications, such as between DDL and 
C++, as illustrated in FIG. 3a. Carre's CMISE gateway is not coupled to a metadata repository. As noted 
above, the CMISE/IDL interface unit cited by the Examiner is clearly not a metadata repository (and neither is 
the CMISE/C++ interface unit) and thus the CMISE Gateway is not coupled to metadata repository. Nowhere 
does Carre describe his CMISE Gateway as being coupled to a metadata repository. Furthermore, Carre's 
CMISE Gateway is not operable to send and receive metadata. Instead, as shown above, the CMISE Gateway 
translates object interfaces as expressed via CORBA RPC request messages (Carre, column 3, line 54 - column 
4, lines 16; and column 5, line 60 - column 6, line 9). 

Additionally, Carre fails to disclose where the metadata gateway provides translation of the metadata to 
and from the database format and an interface definition language. As noted above, Carre's CMISE Gateway 
provides address type conversion between two different object interface specifications, such as between DDL and 
C++, not between a database format and IDL. As noted above regarding the rejection of claim 2, Carre does not 
mention anything regarding converting metadata to or from a database format. Applicants note that the 
Examiner has failed to provide any rebuttal to the above argument. 

The Examiner's rejection of many of the dependent claims is additionally erroneous. For example, the 
cited art is clearly insufficient to support the rejection of claims 2,11, 17, 23 and 28 as discussed in detail in 
Applicants' previous response on pp. 15, 18 and 20-21. 

In light of the foregoing remarks, Applicants submit the application is in condition for allowance, and 
notice to that effect is respectfully requested. If any extension of time (under 37 C.F.R. § 1.136) is necessary to 
prevent the above referenced application from becoming abandoned, Applicants hereby petition for such an 
extension. If any fees are due, the Commissioner is authorized to charge said fees to Meyertons, Hood, Kivlin, 
Kowert & Goetzel PC Deposit Account No. 501505/51 8 1-46200/RCK. 

Also enclosed herewith are the following items: 

^ Return Receipt Postcard 
E^l Notice of Appeal 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: July 18, 2006 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 
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